home *** CD-ROM | disk | FTP | other *** search
/ AMIGA PD 1 / AMIGA-PD-1.iso / NetBSD / docs-netbsd / Mailinglist-Archive / 1994-08.gz / 1994-08 / 000047_owner-amiga@sun…s.berkeley.edu_Tue Aug 2 00:22:36 1994.msg < prev    next >
Text File  |  1994-10-16  |  2KB  |  51 lines
  1. From: "Stephen J. Roznowski" <sjr@zombie.ncsc.mil>
  2. To: donn@u.washington.edu
  3. Subject: Re: Archive Viper 150 not working with 1.0_BETA
  4. Cc: amiga@sun-lamp.cs.berkeley.edu
  5. Sender: owner-amiga@sun-lamp.cs.berkeley.edu
  6.  
  7. > From: Donn Cave <donn@u.washington.edu>
  8. > Subject: Re: Archive Viper 150 not working with 1.0_BETA
  9. > To: sjr@zombie.ncsc.mil (Stephen J. Roznowski)
  10. > Date: Mon, 1 Aug 1994 09:13:28 -0700 (PDT)
  11. > 
  12. > | My Archive Viper tape drive no longer seems to be working under
  13. > | 1.0_BETA.  (940726 sup) using the A3000 kernel. Whenever I attempt to
  14. > | access the drive, I get the following errors:
  15. > | 
  16. > |     st0(ahsc0:4:0): illegal request
  17. > |     st0: cannot set selected mode
  18. > | 
  19. > | But it appears to be found during autoconfig:
  20. > | 
  21. > | ahsc0 targ 4 lun 0: <ARCHIVE VIPER 150  21247-011> SCSI1 sequential removable
  22. > | st0 at scsibus0: rogue, density code 0x0, 512-byte blocks, write-enabled
  23. > 
  24. > Sounds like it's trying to set a bad block size or density.  The ``rogue''
  25. > business means that the driver has specific support for this model, and
  26. > you can get different block size or density settings with different minor
  27. > modes.
  28. > 
  29. > It's kind of random, and I'm not looking at the source (sys/scsi/st.c),
  30. > so I can't say which options are which.  The options are controlled by
  31. > the 4 and 8 bits, plus 1 for no-rewind, so you might try both of them
  32. >   mknod rst4 c 20 4     mknod rst8 c 20 8   (from memory.)
  33.  
  34. I've tried various combinations of device numbers, but none seem to work.
  35. (0-20 if I remember correctly, both block and character).
  36.  
  37. > I have fallen a bit behind in the great race to kernel perfection here,
  38. > and the above really comes from early July.  It may not be worth much,
  39. > since I suppose your tape drive was working at that time.  Still it sounds
  40. > very much like that's the problem.
  41. > 
  42. > I feel like tape support took a big dive when we switched over to the
  43. > main tree, and I'm a little worried that getting fixes into the main tree
  44. > st driver will be difficult.  Hope not.  Your drive has got to be one of
  45. > the more common models in use out there, we could at least hope to work
  46. > with that.
  47.  
  48. I would hope that this will be fixed before 1.0 is out, otherwise, I think
  49. that we are in for some major problems.....
  50.  
  51. -SR